-
Notifications
You must be signed in to change notification settings - Fork 8.4k
[ES|QL] RERANK
command validation support
#221004
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
/ci |
Pinging @elastic/kibana-esql (Team:ESQL) |
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
@drewdaemon can you take this PR review? |
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Module Count
Public APIs missing comments
Page load bundle
Unknown metric groupsAPI count
References to deprecated APIs
History
|
export const isContainedLocation = (container: ESQLLocation, contained: ESQLLocation): boolean => { | ||
return container.min <= contained.min && container.max >= contained.max; | ||
}; | ||
|
||
export const isContained = ( | ||
container: { location?: ESQLLocation }, | ||
contained: { location?: ESQLLocation } | ||
): boolean => { | ||
if (!container.location || !contained.location) { | ||
return false; | ||
} | ||
|
||
return isContainedLocation(container.location, contained.location); | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may be redundant with within
Can we dedupe?
const isParentShowCommand = | ||
!args.length && | ||
(ctx.parent?.node as any)?.type === 'command' && | ||
(ctx.parent?.node as any)?.name === 'show'; | ||
|
||
const formatted = isParentShowCommand ? operator : `${operator}(${args})`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this is fixing an unrelated bug right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain the thinking behind this new pattern? (command definition living in its own module?)
/** | ||
* Return nicely formatted human-readable out of parser errors. This callback | ||
* lets commands construct their own error messages out of parser errors, | ||
* as parser errors have the following drawbacks: | ||
* | ||
* 1. Not human-readable, even hard to read for developers. | ||
* 2. Not translated to other languages, e.g. Chinese. | ||
* 3. Depend on ANTLR grammar, which is not stable and may change in the future. | ||
* | ||
* @param parsingErrors List of parsing errors returned by the ANTLR parser | ||
* for this command. | ||
* @returns Human-readable, translatable messages for the user. | ||
*/ | ||
parsingErrorsToMessages?: ( | ||
parsingErrors: EditorError[], | ||
command: ESQLCommand<CommandName>, | ||
references: ReferenceMaps | ||
) => ESQLMessage[]; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Till now we have relied on a clean passthrough of ANTLR errors despite their limitations. This new idea raises the following questions for me
- When is this expected?
- Do we need to add these for every new command?
- Which messages are important enough to give this special treatment to? Surely not all messages?
- We don't control the parser messages. How often will they change in our grammar update PRs, requiring us to update this logic?
- Is it ok to introduce this on an ad-hoc basis (as we have here) or should we do it holistically for all commands (if we're going to do it)?
Summary
Partially addresses #217285
Checklist